home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 001245_daemon _Thu Jun 10 21:03:01 1993.msg < prev    next >
Internet Message Format  |  1994-01-24  |  5KB
  1. Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  2.     id AA00929; Thu, 10 Jun 93 21:03:03 MET DST
  3. Return-Path: <raisch@ora.com>
  4. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  5.     id AA00925; Thu, 10 Jun 93 21:03:01 MET DST
  6. Received: from [140.186.65.25] by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
  7.     id AA15628; Thu, 10 Jun 1993 21:24:49 +0200
  8. Received: by ora.com (5.65c/Spike-2.1)
  9.     id AA29410; Thu, 10 Jun 1993 15:24:24 -0400
  10. Date: Thu, 10 Jun 1993 15:24:24 -0400
  11. From: raisch@ora.com (Rob Raisch)
  12. Message-Id: <199306101924.AA29410@ora.com>
  13. To: www-talk@nxoc01.cern.ch
  14. Subject: <TITLE>Current Server Work at O'Reilly....</TITLE>
  15.  
  16.  
  17. >Newsgroups: comp.infosystems.www
  18. >Path: ora.com!raisch
  19. >From: raisch@ora.com (Rob Raisch)
  20. >Subject: <TITLE>Current Server Work at O'Reilly....</TITLE>
  21. >Message-ID: <C882F3.LxH@ora.com>
  22. >Organization: O'Reilly & Associates, Inc.
  23. >Date: Sun, 6 Jun 1993 22:57:02 GMT
  24.  
  25.     We have a project which will use WWW to deliver a product from ORA to
  26. users who have 'subscribed.'  This will be a free product, but we will need
  27. to collect information from the user-base to be able to generate demographics
  28. which will ultimately pay for the project (we hope.)  (BTW, can't talk about
  29. it, wait for the 'official' announcement.)
  30.  
  31.     I've made modifications to the NCSA server code to support two features
  32. of the new HTTP protocol spec which will allow us to log who is accessing this
  33. 'product.'  I've added support for the 'From:' and 'User_Agent:' fields in
  34. server queries to know who is asking and what they are using to retrieve.
  35.  
  36.     It has occured to me that there are some decisions a server might make, 
  37. given a very little information regarding the browser the user is using.
  38.  
  39.     I would like to propose the following format for the 'User_Agent:'
  40. field, and see what people think:
  41.  
  42.     User_Agent: NAME VERSION CAPABILITIES
  43.  
  44.     Where the name and version would be defined by the browser maker, 
  45. and the CAPABILITIES would come from a list like:
  46.  
  47.         TEXT         (does this really need to be said?)
  48.         INLINE_GIF    (gifs inlined ala mosaic)
  49.         GIF,JPG,PS     (various graphics)
  50.         GHOSTVIEW
  51.         MOUSE
  52.         AUDIO,VIDEO    (supports audio or videofiles)
  53.         MAIL,NEWS,FTP    (supports these local services)
  54.         FAST        (on an ETHER connection)
  55.         SLOW        (on a SLIP dialup)
  56.         ...         (many possible capabilities to be defined)
  57.  
  58.  
  59.     The theory here is that documents can be rewritten 'on the fly' to
  60. reference only those capabilities which the user has at hand.
  61.  
  62.     Further assume that I have a method of managing documents locally which 
  63. return portions of a document based on capability metrics.
  64.  
  65.     For example:
  66.  
  67.     I am a user, using Lynx on a VTxxx.  When I make a request to the 
  68. server, Lynx also sends:
  69.  
  70.         User_Agent: Lynx 1.06 TEXT MAIL NEWS
  71.  
  72. since these are the capabilities which Lynx running on my host supports.
  73.  
  74.     The server then retrieves the following document
  75.  
  76. ------------------------------------------------------------------------------
  77. <HTML>
  78. <HEAD>
  79. <TITLE>This is a document</TITLE>
  80. </HEAD>
  81. <BODY>
  82.  
  83. #ifdef GRAPHICS
  84.  
  85. #    ifdef GIF
  86.  
  87.     <IMG HREF=(some gif file)>
  88.  
  89. #    elif JPG
  90.  
  91.     <IMG HREF=(some jpg file)>
  92.  
  93. #    endif
  94.  
  95. #else
  96.     There is an inline graphic here which cannot be rendered 
  97.     locally.  It can be retrieved by hand as:
  98.  
  99. #    ifdef FTP
  100.  
  101.     ftp://hostname/dir/file
  102.  
  103. #    elif MAIL
  104.  
  105.     "/dir/file" from hostname
  106.  
  107.     by using the the ftp->mail gateway at Hostname with the 
  108.     following commands:
  109.         Get blahblahblahblahblah
  110. #    endif
  111.  
  112.  
  113. #endif
  114.  
  115. </BODY>
  116. </HTML>
  117. -----------------------------------------------------------------------------
  118.  
  119.     (For the non-developers in the audience, the #-commands are from the
  120. standard Unix C language pre-processor.)
  121.  
  122.     And makes the proper macro expansion to send the best document
  123. back to meet the requirements of the User_Agent.
  124.  
  125.     I would get, on the browser end, something which looked like:
  126.  
  127. -----------------------------------------------------------------------------
  128. <HTML>
  129. <HEAD>
  130. <TITLE>This is a document</TITLE>
  131. </HEAD>
  132. <BODY>
  133.     There is an inline graphic here which cannot be rendered 
  134.     locally.  It can be retrieved by hand as: "/dir/file" from hostname
  135.  
  136.     by using the the ftp->mail gateway at Hostname with the 
  137.     following commands: Get blahblahblahblahblah
  138. </BODY>
  139. </HTML>
  140.  
  141. -----------------------------------------------------------------------------
  142.  
  143.     Note that the macro document never leaves the system, only the 
  144. particular rewritten version which answers the needs of the reader.
  145.  
  146.     Thoughts?  --</rr>